ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98a.txt/000036_icon-group-sender _Wed Feb 11 12:26:35 1998.msg

Internet Message Format | 2000-09-20 | 4KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id MAA07223
    for <[e-mail]>; Wed, 11 Feb 1998 12:26:34 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA21177; Wed, 11 Feb 1998 12:26:33 -0700
From: [e-mail]
Date: Wed, 11 Feb 1998 12:29:30 -0600
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Subject: Re: Stand-alone executables
To: [e-mail]
X-Mailer: SPRY Mail Version: 04.00.06.17
Errors-To: [e-mail]
Status: RO
Content-Length: 2826

>... If I had a
method of bundling the interpreter and application code, I would gave
gotten away with using Icon much more in my jobs outside of the
university.

Of course, for MS-DOS systems a simple batch file can make an interpreter/code
package LOOK (to the operator) like an "executable"... sometimes this is enough,
all by itself.  (You can even "cheat" a little by renaming the code file with a
more-familiar extension such as ".DLL".)   :-)

> At Texas Instruments, I worked on an assembly source to
assembly source translator that was based on a terribly hacked up version
of the assembler.

I'm intrigued, I thought I was the only person who did assembly-language
cross-compilers.  :-)  I did one that cross-compiles Motorola 68000 assembler
source code into Intel-flavor assembler source code.  :-)   (I used that one in
conjunction with an Atari-ST to PC video game conversion project... quite a few
years ago now).  That one was written in S*BOL.

> If I could have created a standalone Icon executable, I
could have written the translator in Icon.  My experience with the Icon
compiler was that the resulting source was too large; so, the executable
would be too large.  This would have drawn the attention of my
knuckle-headed supervisors.

I'm rather amazed that the Icon program would be "too large"... in my
experience, it's rare to have really big programs there.  My converter is
something like 2K lines of S*BOL, best as I can recall.  Largeish as S*BOL
programs go.  I don't doubt that SPITBOL 386 would compile it with consummate
ease, although at the time I was running it on an 8086-based Amstrad processor
(essentially an XT) under SNOBOL4+ and it ran fine even on that limited
platform.

Of course, SPITBOL will also produce .EXE files and this would have allowed you
to solve that problem for your company.

> Ideally one would like a platform independent way of attaching the input
to the interpreter to the end executable and to inform the interpreter to
start reading at the some point in its own executable.  Perl2exe does this
without recompiling perl.

I personally am quite willing to give up "platform independence" since virtually
all the systems one runs into in the "real world" are PC-based.  Or at least
that's very true in the client circles our company deals with.

And given the fact that we can get **very** capable multimedia PCs for less than
$500 (add $150 for a 14" color VGA monitor), it's fairly ridiculous to do
without one if you want to run a program which runs well on that platform.  The
entire machine to run the program costs about the same as just ONE day of
consulting time... see why "multiplatform" matters SO little?

Gordon Peterson
http://www.computek.net/public/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/